Community messaging lists for authorization to deliver electronic messages

ABSTRACT

A third-party can subscribe to one or more electronic message group lists without joining the group lists by creating a trust relationship between the subscriber and a group list member. In particular, the subscriber can send a trust indicator to the group member, who can then determine whether to accept the trust indicator for all or specific groups that are associated with the group member, as appropriate. In at least one embodiment, the group member can send a trust indicator acceptance message to the subscriber that identifies the group member, and any or all group lists associated with the group member. The subscriber can then receive messages directed to the trusted group member or group lists, and can send group messages to the group lists subject to a receive setting associated with the group lists or group members of the group lists.

CROSS-REFERENCE TO RELATED APPLICATIONS

This invention claims the benefit of priority to U.S. Provisional PatentApplication No. 60/531,536, filed on Dec. 19, 2003, entitled “CommunityMessaging Lists for Authorization to Deliver Electronic Messages”, theentire contents of which are incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. The Field of the Invention

The present invention relates to systems, methods, and computer programproducts for implementing electronic messaging lists. In particular, theinvention relates to systems, methods, and computer program products forimplementing group messaging lists based on trust mechanisms.

2. Background and Relevant Art

Electronic messages such as email and instant message systems havebecome a convenient method of communication for a growing number ofpeople and businesses. One problem with such systems, however, is thatit is now fairly common to receive unsolicited messages, particularlyfrom unknown persons or entities. Accordingly, a number of filteringsystems have been developed to avoid inefficiencies associated withhaving to read and/or summarily delete vast sums of messages fromunknown recipients, or from suspect content providers.

For example, content-based filtering systems may filter out messagesbased on content typically found in advertisements, content that isoffensive in one or more ways, or the like. Unfortunately, these typesof filters may also accidentally filter out messages from trustedfriends or family based on an errant analysis of the email content.

A “white list”-based filtering system, on the other hand, typicallyfilters out messages based on an advanced trust of the sending entity'smessaging address. This advanced trust can be created when the user ofthe white list sends a message to trusted people or entities, or whenthe user manually enters one or more trusted messaging addresses in thewhite list. Those whom the user trusts can then correspond with the userof the white list without additional challenges. Unfortunately,white-list filters typically do not filter out messages between the userof the white list and trusted members of the list based on categories ofinformation, or secondary characteristics of the list members (e.g.,family, friend, etc.) Furthermore, white lists do not typically lettrusted members of the list identify each other, and therefore send andreceive messages to each other.

Another type of filtering system is group-based messaging (also referredto as a “group list” or “message group list”), which is similar in somerespects to white lists, and filter messages based one or moreaddresses, as well as an additional group or category. For example, asshown in FIG. 1A, a user 105 may create a group list that includescertain members in a “family” group list 110, and includes other membersin a “friends” 120, or other organization group list, such as a“research” group 130. As shown in FIG. 1B, when the user 105 sends amessage 180 to a group 110 address, each group member (e.g., 140, 150,160, 170) of group 110 receives the message 180 without additionalchallenges. In addition, each group member (e.g., 140, 150, 160, 170) inthe group may also identify the other group members, and so may alsocorrespond with other group members without challenge.

One advantage of group message lists is that send and receive authoritywithin the group depends primarily on group membership, thus prohibitingnon-members from having the same interaction with the group. Thus, forexample, all members of an “accounting” group may be automaticallyenabled to send and receive accounting group messages, but not send orreceive “research” group messages. Unfortunately, persons who may beappropriate for viewing or sending certain group messages, but areotherwise persons not designated as group members, cannot view, send, orreceive messages intended for the group without some difficulty.

For example, within an organization, a research employee may ask thegroup creator to add the research employee to an accounting membershiplist. The group administrator, however, may be reticent in adding theresearch employee to the accounting message group, since it may beinappropriate to give the research employee all the relevant send andreceive privileges inherent to other group members of that group. Assuch, a client that is a non-member of the group may rely on asking atrusted member of a given group list to forward certain group-specificmessages to the client. One can appreciate that it would be fairlyinefficient for the client to rely on the group member's time and effortto forward the requested messages directed to one group, much lessseveral groups.

Accordingly, an advantage in the art can be realized with systems,methods, and computer program products that implement trust-basedmechanisms between groups, group members, and group non-members. Inparticular, it would be an advantage in the art to be able to combinethe benefits of a white list with the benefits of a group messagingsystem, and thereby improve the efficiency of distributing messages in atrusted fashion.

BRIEF SUMMARY OF THE INVENTION

The present invention solves one or more of the foregoing problems inthe art with systems, methods, and computer program products for sendingor receiving group messages between group members and subscribersthrough trust-based systems. In particular, a group subscriber canreceive messages directed to a specific group by indicating a level oftrust with a member of the group. The subscriber can also send messagesto the corresponding group members that have indicated a level of trustwith that subscriber.

For example, in one implementation of the present invention, a groupmember can create, or simply belong to, one or more group message liststhat include a corresponding electronic address for each of one or moregroups and/or group members. Each of the group members of each grouphave a similar level of trust within the group, such that each of thegroup members can identify, send and/or or receive messages to or fromthe group, or to or from other group members within the group withoutchallenge.

A non-member of any given group can subscribe to one or more of thegiven groups by indicating a level of trust with the group member. Ifthe trust request is accepted, the non-member becomes a subscriber tothe requested group. After creating a trust relationship with the groupor group member, the subscriber can then receive messages directed tothe group generally, or from any group member sending a specific messagedirectly to the subscriber. By contrast, messages the subscriber sendsto the group or any group members are subject to a trust challenge.

Additional features and advantages of the invention will be set forth inthe description which follows, and in part will be obvious from thedescription, or may be learned by the practice of the invention. Thefeatures and advantages of the invention may be realized and obtained bymeans of the instruments and combinations particularly pointed out inthe appended claims. These and other features of the present inventionwill become more fully apparent from the following description andappended claims, or may be learned by the practice of the invention asset forth hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and otheradvantages and features of the invention can be obtained, a moreparticular description of the invention briefly described above will berendered by reference to specific embodiments thereof which areillustrated in the appended drawings. Understanding that these drawingsdepict only typical embodiments of the invention and are not thereforeto be considered to be limiting of its scope, the invention will bedescribed and explained with additional specificity and detail throughthe use of the accompanying drawings in which:

FIG. 1A illustrates a prior art block diagram of a group member that isa member of multiple group lists;

FIG. 1B illustrates a prior art block diagram for sending and receivingmessages between a group member and other group members of one of thegroup lists illustrated in FIG. 1A;

FIG. 2A illustrates a block diagram in accordance with an implementationof the present invention in which a subscriber and a group membergenerate a trust relationship between the subscriber and all groupsassociated with the group member;

FIG. 2A illustrates a block diagram in accordance with an implementationof the present invention in which a subscriber and a group membergenerate a trust relationship between the subscriber and only somegroups associated with the group member;

FIGS. 3A and 3B illustrate a block diagrams in accordance with animplementation of the present invention in which a subscriber is able toreceive different group messages from different group members;

FIG. 3C illustrates a block diagram in accordance with an implementationof the present invention in which the subscriber sends a group messageto a trusted group list, subject to one or more challenges;

FIG. 4 illustrates a method for performing a method of establishing atrust relationship between a subscriber and a group member, inaccordance with an implementation of the present invention; and

FIG. 5 illustrates a method for relaying messages between a group memberor a group list and a subscriber, in accordance with an implementationof the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention extends to systems, methods, and computer programproducts for sending or receiving group messages between group membersand subscribers through trust-based systems. In particular, a groupsubscriber can receive messages directed to a specific group byindicating a level of trust with a member of the group. The subscribercan also send messages to the corresponding group members that haveindicated a level of trust with that subscriber.

As a preliminary matter, a “subscriber” will be understood to mean anythird-party, such as a group non-member, an electronic alias that refersto the group non-member, an organization, or any other type of entitythat is not initially included in a group list membership, but later (orpresently) can communicate with the group list based on a created trustrelationship. A “group list”, “message group list”, or “group” asalready herein described, will be understood to mean an electronicmessage list that includes one or more electronic addresses organizedunder a common theme. A “group member” will be understood to mean anymember of a group list, such as a group creator, group administrator, orordinary group member included in the group list.

FIGS. 2A through 2B are block diagrams that illustrate an implementationin which a subscriber generates a trust relationship with one or moregroup lists, in order to receive one or more group messages. Forexample, group member Aaron 205 (or, e.g., group members 240, 250, 260,or 270) may forward a group list message to subscriber 200. Thesubscriber 200 might decide that, based on the subscriber's 200knowledge of group member Aaron 205 (or relevant group member), and/orbased on the content of the message 180, the subscriber 200 “trusts”messages sent by group member Aaron 205, or would like to read messagessent to groups to which member Aaron 205 belongs.

Accordingly, FIG. 2A shows that the subscriber 200 sends a trustindicator 203 to group member Aaron 205. For the purposes of thisspecification and claims, a “trust indicator” 203 can be a separateelectronic message sent from the subscriber to a group member 205 thatindicates the subscriber's 200 identity, and/or a request to send and/orreceive electronic communication with the group member's 205 associatedgroup lists (e.g., 210, 220, 230). The trust indicator 203 can include adigital identification certificate, such as a digital signature, or anyother type of electronic identifier, such as a security token and keysystem. In other implementations, the trust indicator message 203includes information such as the subscriber's physical or virtualnetwork addresses, one or more electronic message addresses, and soforth.

When the group member 205 receives the trust indicator 203 from thesubscriber 200, the group member 205 can grant or deny the trustindicator 203 in a variety of different ways. In one implementation, forexample, the group member 205 responds to the subscriber 200 with atrust indicator acceptance message 207. A trust indicator acceptancemessage 207 is an electronic message that can include variousidentification and/or security certificates, similar to those describedabove for the trust indicator 203. The trust indicator acceptancemessage 207 can also include other types of information, such as a groupname electronic message address, network routing information, level ofreciprocal trust from the group member 205 to the subscriber 200, and soforth.

In another implementation, the group member 205 responds to thesubscriber 200 by automatically sending a challenge to the subscriber200. For example, response message 207 can include text that requiresthe subscriber to read the automatic response, type data containedwithin the automatic response, and send a new confirmation message thatincludes the typed data. If the subscriber's response (not shown) isappropriate, the group member 205 grants the subscriber 200 access tothe group list by creating a trust relationship. In anotherimplementation, a challenge and response mechanism is based primarily onthe subscriber's network address. If the subscriber's network address isvalid and trusted, a trust relationship is created. Accordingly, thereare a wide variety of authentication and challenge/response mechanismsthat can be implemented in accordance with the present invention.

Once the trust relationship is created, the subscriber 200 is, ineffect, added to the trusted group list for outgoing messages on anunlimited basis, and allowed to send messages to the group on a limitedbasis, based on one or more group or group member settings. For example,the trust relationship can generate a corresponding relay mechanism,such as an address forwarding file in the group list that includes thesubscriber's electronic address, or one or more electronic addresses forother trusted subscribers. As previously indicated, however, the relaymechanism allows the subscriber 200 to receive messages from each groupwithout challenge, but to primarily send messages to each group, or toeach corresponding group member, subject to OD z additional challenges.For example, the subscriber 200 may send a message to group Family 210,but if none of the group members of Family 210, except for group memberAaron 205, have created a trust relationship with the subscriber 200,only group member Aaron 205 would be able to view the subscriber'smessage.

As shown in FIG. 2B, the subscriber 200 and group member Aaron 205 canalso create a more limited trust relationship, such that the subscriber200 has a trust relationship for less than all of the group listsassociated with group member Aaron 205. This can be by choice of thesubscriber 200 or the relevant group member, or the relevant groupmember may have settings configured to allow outside access only tocertain groups (e.g., group 220, but not group 230). This limited grouptrust can also be based on communication made between the subscriber 200and relevant group member during a challenge and response sequence aspreviously described, such that a certain subscriber response meritsaccess to group 210, and a certain other subscriber response meritsaccess to group 210 and 220.

For example, as shown in FIG. 2B, subscriber 200 sends a limited trustrequest 215 to group member Aaron 205 so that subscriber 200 cancommunicate only with “Family” group 210. In turn, group member Aaron205 can grant the trust indicator 215, by sending a trust indicatoracceptance message 209 that is similar to trust indicator acceptancemessage 207. The trust indicator acceptance message 209 can be of thesame form as already described herein, and can include detailedconfiguration data for how the subscriber 200 can interact with theentire Family group 210, and/or various members of the group 210 (e.g.,240, 250, 260, 270). Accordingly, group member Aaron 205 creates a trustrelationship with subscriber 200, which allows subscriber 200 tocommunicate with family group 210 within varying limits of trust.

One will appreciate that these varying limits of trust can be configuredfor a wide range of options that are appropriate for differentcircumstances from group to group, or from group member to group member.For example, it may be that a potential subscriber would like to viewcertain messages from a research group (e.g., group 230), but not allmessage directed to the research group. In particular, the subscribermay wish to review research group messages that pertain particularly toscheduling issues. On the other hand, the group list members or grouplist administrator may desire to keep most research group messagesinternal to the group members, particularly those concerning sensitivetechnologies. Accordingly, the group list administrator may allow groupmembers only to allow a trust relationship for messages that conform tocertain content regulations, such as those specifically labeled as“scheduling”. Similarly, a group member may desire to designate whichoutgoing group messages can be sent to trusted subscribers, and whichmust remain internal only.

In another example, a group member (e.g., 240) can configure “receive”permissions differently for different groups when joining the groups, orat some later point in time as a group member. For example, group member240 may configure receive settings for group 210 so that group member240 accepts all group member (e.g., 205, 250, 260, 270) messages (e.g.,FIG. 3A, message 225) as well as group subscriber 200 messages (e.g.,FIG. 3C, message 245) to group 210 without challenge. Similarly, groupmember 240 may configure the receive settings of group 220 so that groupmember 240 accepts all group member messages without challenge, butchallenges any subscriber 200 messages (e.g., FIG. 3C, message 245) togroup 220. The group member may still trust certain types of subscribersand not others, such that the group member accepts messages from certainsub-classes of subscribers to group 220, and challenges messages sent byother sub-classes of subscribers.

In another example, a given group may be configured with defaultsubscriber receive privileges that are inherent in group listmembership. One such default setting can provide that all group membersof the group list receive group messages from group members to thegroup, and also receive any group messages sent by any subscribers tothe group without challenge. For example, a given agent may haveestablished a trust relationship with an employee of company C. If thegroup list for company C is configured such that all group list Cmembers of company C are to receive subscriber messages, all employees(i.e., group members) of company C will receive group mail sent by theagent (the subscriber) to company C without challenge, even though theagent is only a subscriber of the company C mail list.

Similarly, a given group may be configured with different subscriberaccept privileges when the subscriber subscribes to the group list. Onesuch default setting can provide that group messages from one class ofsubscribers of the group list (those having send and receive rights)send group messages to, and receive group messages from, another classof subscribers (having receive rights only) to the group list, and alsoreceive any group messages sent by other group members to the groupwithout challenge. For example, a given agent may have established atrust relationship with an employee of company C that grants send andreceive privileges to the group without challenge. Another employee ofcompany C may have also granted a receive-only trust relationship withanother third-party subscriber. Accordingly, the agent subscriber cansend group messages to the group list that are received by the groupmembers of the group without challenge, and also by the third-partysubscriber without challenge. By contrast, group messages sent to thegroup list by the third-party subscriber can be subject to challenge byeach of the non-trusted group members, and also subject to challenge bythe agent subscriber.

In still another example, one group list can also establish a reciprocaltrust relationship with another group list. For example, two independentcompanies may be involved in a partnership on one project, or may beinvolved in a corporate merger of some sort. Rather than necessarilycreating a new group list for the project, or for the new company, therespective group lists may create a trust relationship with each other,such that group list A of company A is now subscribed to group list B ofcompany B, subject to any variable send and receive settings.

In one possible setting of a group-to-group trust relationship, allgroup members of group list A can send messages to, and receive messagesfrom, any group member of group list B. In another possible setting, thegroup lists A and B have generic, reciprocal send and receive privilegesbetween group members of lists A and B, while group members of grouplist A only receive messages from subscribers (or sub-classes ofsubscribers) to group list B subject to challenge, and vice versa. Assuch, there are myriad ways in which a trust relationship can beimplemented between a subscriber and a group member, a subscriber and agroup list, from one group list to the members of the next group list,or from one group list to the subscribers of the next group list, and soforth.

In any event, and notwithstanding the preceding examples, FIGS. 3Athrough 3C illustrate block diagrams for the simplest case of sendingand receiving messages 225, 235, 245, in which the subscriber 200 andonly group member 205 of group 210 have created a generic trustrelationship. As shown in FIG. 3A, for example, group member Aaron 205,who may be the group 210 creator, sends a message 225 to the group 210via the address “family@domain.net”. When the message 225 is sent, eachof the group members such as Nathan 240, Heather 250, Katie 260, andChristina 270 can be sent a copy of the message. In addition, because atrust relationship exists (e.g., through trust indicator 203, or 215)between the subscriber 200 and group member Aaron 205, subscriber 200also can be sent a copy of the message 225.

As shown in FIG. 3B, group member Nathan 240, who is a member of Familygroup 210, can send a group message 235 to group 210 via the address“family@domain.net”, such that each of the recipients, including thesubscriber 200 receive the message 235. In particular, the creation of atrust relationship between group member Aaron 205 and subscriber 200effectively adds a trust relationship to each of the corresponding groupmembers of group 210, subject to any other limits described herein.Thus, when group member Nathan 240 sends a group message 235 to group210, group member Aaron 205, group members Heather 250, Katie 260,Christina 270, and subscriber 200 can each receive a copy of the message225.

When the subscriber 200 sends a message to the group 210, however, aslightly different mechanism can occur. In particular, since only groupmember Aaron 205 has implemented a trust relationship with thesubscriber 200, when the subscriber 200 sends the message 245 to group210, only group member Aaron 205 receives the message 245 withoutchallenge. In another implementation, the message 245 is also sent toeach of group members Nathan 240, Heather 250, Katie 260, and Christina270, such that each person can subject the message 245 to challenge. Instill another implementation, a protocol at the group list domain serverfor “family@domain.net” subjects the message 245 to challenge based onknown instances of created trust relationships, before (or in lieu of)sending the message 245 to each group member.

The present invention may also be described in terms of methodscomprising functional steps and/or non-functional acts. FIGS. 4 and 5illustrate an exemplary flow chart for creating and/or relaying groupmessages using trust mechanisms. The methods of FIGS. 4 and 5 will bediscussed with respect to the diagrams illustrated in the precedingFigures.

For example, FIG. 4 illustrates an implementation of the presentinvention for communicating a group message between a subscriber and oneor more group members in the one or more group lists without thesubscriber having to separately join the one or more group lists. Inparticular, FIG. 4 shows that the method comprises an act 300 ofidentifying a group member and a group list. Act 300 includesidentifying a group member and one or more group lists associated withthe group member. For example, subscriber 200 can receive a message thathas been forwarded to the subscriber 200 by a group member (e.g., groupmember 205). Alternatively, the subscriber 200 can have prior knowledgeof the relevant group member, and desire to communicate with the groupmember through an associated, identifiable group, such as group 210,220, 230.

FIG. 4 illustrates that the method further comprises a functional,result-oriented step 340 for creating an electronic message trustrelationship using a trust mechanism. Step 340 comprises anycorresponding acts for creating an electronic message trust relationshipbetween a subscriber and the identified group member using a trustmechanism, whereby the trust relationship allows the subscriber tocommunicate with the identified group member and one or more other groupmembers in the identified one or more group lists without requiring thesubscriber to join the identified one or more group lists. Asillustrated, however, step 340 comprises act 310 of sending a trustindicator. Act 310 includes sending a trust indicator by a subscriber tothe identified group member. For example, subscriber 200 can send anelectronic trust indicator message 203, 215 that includesidentification, routing information, security information, and anynecessary challenge/response information to a group creator, such asgroup member 205.

FIG. 4 also illustrates that step 340 comprises an act 320 of receivinga trust acceptance indicator. Act 320 includes receiving a trustacceptance indicator that indicates that the group member has acceptedthe trust indicator, wherein the subscriber can receive messagesdirected to at least one of the identified one or more group lists. Forexample, if the group member (e.g., group member 205) agrees to therequested trust relationship, the relevant granting entity can send anelectronic response message 207, 209 to the subscriber 200 thatacknowledges the trust indicator request 203, 215, and provides therelevant instructions for communicating through the trust relationship.These instructions can include any electronic message addresses, anyrouting information, any group membership information, and any othertrust acceptance information as appropriate.

FIG. 4 also illustrates that step 340 comprises an act 330 of relaying agroup message. Act 330 includes relaying a group message between one ormore group members in the at least one of the identified one or moregroup lists and the subscriber. For example, the trusted group member205 can send a message 225 to the group 210, such that the message 225is sent to each original group member of a group 210, and also tosubscriber 200 based on the trusted relationship. Similarly, anon-trusted group member 240 can send group message (or personalmessage) to group member 205, which is also copied to subscriber 200based on the trusted relationship. By contrast, the subscriber 200 canalso send a group message 245 to the group list 210, subject to areceive setting by the group 210 or group members (e.g., 205, 240, 250,etc.) For example, if a non-trusted group member has a receive settingthat challenges any messages by a subscriber, the group message sent bythe subscriber 200 can be accepted by the trusted group member 205, butsubject to challenge by other non-trusted group members (e.g., groupmember 240).

FIG. 5 illustrates another method in accordance with the presentinvention, albeit primarily from the group list or group memberperspective. In particular, FIG. 5 illustrates a method for relayingmessages between group members and a subscriber based on one or moretrust relationships. For example, the method shown in FIG. 5 comprisesan act 400 of accepting a trust relationship. Act 400 includes an act ofa group member 205 accepting a trust relationship with a subscriber 205,such that the subscriber 205 is capable of receiving group messages sentto a group (e.g., group 210, 220, 230, etc.) to which the group memberbelongs. For example, in response to a trust relationship request (e.g.,203, 215) sent from a group non-member, the group member, or group listadministrator, accepts the request for the trusted relationship bysending a corresponding trust acceptance (e.g., 225, 235).

The method shown in FIG. 5 also comprises a step 440 for relayingmessages to and from the subscriber with different levels of challengeand response. In particular, step 440 includes relaying messages to andfrom the subscriber with different levels of challenge and response,such that the subscriber can receive messages without challenge that aredirected to the group list, and such that group members that have nottrusted the subscriber subject messages to the group sent by thesubscriber to a receive setting. For example, a trust mechanism set upwith the group list (e.g., 210, 220, 230) enables the subscriber 200 toreceive all group messages (e.g., 225, 235) sent from any group membersto the group list. Furthermore, a receive setting that involves achallenge mechanism at the group list domain server, or at the computersystems for each group member, subjects the subscriber's group messageto challenge where no trust relationship exists for a given groupmember.

Although step 440 can comprise any number or order of correspondingacts, FIG. 5 shows that the step 440 comprises an act 410 of sending agroup message to a group list to a subscriber. Act 410 includes sendinga group message by a group member to a group list to a subscriber, suchthat a trusted subscriber receives any messages sent to the group list,or sent directly to the subscriber by an individual group member. Forexample, if a group member 240 sends a message 235 to the group list210, the group domain server sends a duplicate of the message 235 toeach group member (e.g., 205, 250, 260, 270), and also sends a duplicateof the message 235 to the subscriber 200.

Step 440 also comprises an act 420 of receiving a group message from thesubscriber. Act 420 includes receiving a group message from thesubscriber that is directed to the group list. For example, based on thetrust relationship, the subscriber 200 can send a message 245 that isdirected to a group list 210. In one implementation, the message 245 isreceived at a group list server; while in another implementation, themessage 245 is not subject to challenge until it reaches, for example, amessage interface at the individual group member's computer system.

FIG. 5 further shows that step 440 comprises an act 430 of challengingthe group message from the subscriber for all non-trusted group members.Act 430 includes challenging the group message from the subscriber forall non-trusted group members, such that non-trusted group members onlyreceive the group message from the subscriber with group memberintervention, and such that trusted group members receive the groupmessage from the subscriber without intervention. For example, as shownin FIG. 3C, since group member Aaron 205 is the only group member ofgroup 210 to have generated a trust relationship with the subscriber200, only group member Aaron 205 will receive the message 245 withoutchallenge, while group members 240, 250, 260, and 270 will each refusethe message 245 unless the subscriber 200 also passes an additionalchallenge and response with those corresponding group members.

Accordingly, implementations of the present invention provide a widerange of flexibility for distributing group messages inside and outsideof group lists. Furthermore, implementations of the present inventionprovide increased efficiency for distributing group messages that arealso appropriate to be viewed by group non-members. In addition,implementations of the present invention allow group messages to bedistributed to group non-members only on a trusted basis, therebyimproving distribution techniques without significantly limiting issuesassociated with receiving and delivering unsolicited messages.

The present invention may be embodied in other specific forms withoutdeparting from its spirit or essential characteristics. The describedembodiments are to be considered in all respects only as illustrativeand not restrictive. The scope of the invention is, therefore, indicatedby the appended claims rather than by the foregoing description. Allchanges that come within the meaning and range of equivalency of theclaims are to be embraced within their scope.

1. In a computerized environment that includes an electronic messagingservice, a group member, and one or more group lists associated with thegroup member, a method of relaying a group message between a subscriberand one or more group members in the one or more group lists without thesubscriber having to separately join the one or more group lists, themethod comprising the acts of: identifying a group list and one or moregroup members of the group list; sending a trust indicator by asubscriber to one of the one or more group members; sending a trustacceptance indicator by the one group member to the subscriber, whereinthe trust acceptance indicator indicates that the one group member hasaccepted the trust indicator, such that the subscriber can receive groupmessages sent to the identified group list; and the subscriber receivinga group message sent by any of the one or more group members to thegroup list.
 2. The method as recited in claim 1, wherein identifying agroup list and one or more group members of the group list includes oneor more of the subscriber receiving an electronic message from the onegroup member, and the subscriber receiving a digital signatureassociated with the one group member.
 3. The method as recited in claim1, wherein the trust indicator includes an identifier for at least oneof a specific group list associated with the one group member, anelectronic message address for the subscriber, a username and passwordassociated with the subscriber, and a digital signature associated withthe subscriber.
 4. The method as recited in claim 1, wherein the onegroup member is the creator of the group list.
 5. The method as recitedin claim 1, wherein the trust indicator includes only a request toreceive the group message.
 6. The method as recited in claim 1, whereinthe trust indicator includes a request to receive group list messagesfrom additional group lists associated with the one group member.
 7. Themethod as recited in claim 1, further comprising the one group membersending a challenge message to the subscriber that requests a specifiedresponse from the subscriber prior to accepting the trust indicator. 8.The method as recited in claim 1, further comprising generating anapproval list, the approval list including one or more trustedsubscribers, one or more corresponding routing instructions, and a setof instructions for allowing the one or more trusted subscribers toreceive messages from the group.
 9. The method as recited in claim 1,wherein at least first and second group lists are associated with theone group member, and wherein each of the first and second group listshave a different trust configuration that differentiates sending orreceiving of a group message based on content of the group message. 10.The method as recited in claim 9, wherein the method further comprisesan act of: sending a first group message by the one group member toother of the one or more group members in the first group list based oncontent identified in the first group message, wherein the subscriberdoes not receive the first group message; and sending a second groupmessage by the one group member to the other of the one or more groupmembers and to the subscriber of the first group list based on thecontent of the second group message.
 11. The method as recited in claim1, wherein the identified group list comprises a non-trusted secondgroup member, and wherein a receive setting is associated with one ormore of the identified group list and the non-trusted second groupmember.
 12. The method as recited in claim 11, wherein the receivesetting indicates that the non-trusted second group member can receive agroup message sent by the subscriber to the identified group list. 13.The method as recited in claim 11, wherein the subscriber is identifiedas part of a sub-class, and wherein the receive setting indicates thatthe non-trusted second group member can receive a group message sent byany subscriber that is part of the sub-class.
 14. The method as recitedin claim 11, wherein a second group list is subscribed to the identifiedgroup list, and wherein a group message sent by the subscriber to thegroup list is also sent to the second group list.
 15. In a computerizedenvironment that includes an electronic messaging service, a groupmember, and one or more group lists associated with the group member, amethod of communicating a group message between a subscriber and one ormore group members in the one or more group lists without the subscriberhaving to separately join the one or more group lists, the methodcomprising: an act of identifying a group member; and a step forcreating an electronic message trust relationship between a subscriberand the identified group member using a trust relationship, such thatthe subscriber can communicate with one or more group lists associatedwith the group member without requiring the subscriber to join the oneor more group lists.
 16. The method as recited in claim 15, wherein thestep for creating an electronic message trust relationship comprises: anact of sending a trust indicator by the subscriber to the identifiedgroup member; an act of receiving a trust acceptance indicator thatindicates that the group member has accepted the trust indicator,wherein the subscriber gains communicative access to a group listassociated with the group member; and an act of sending a group messagefrom the group member or any other group members of the associated grouplist to group list, such that the subscriber receives the group message.17. In a computerized system, including a group member, and one or moregroup lists associated with the group member, a method for relayingmessages between group members of a group list and a subscriber based onone or more trust relationships, the method comprising: an act of agroup member of a group list accepting a trust indicator from asubscriber, such that the group member is a trusted group member; a stepfor, based on the accepted trust indicator, relaying a group message tothe group list from the subscriber, and relaying a group message fromany group member of the group list to the subscriber, such that thesubscriber receives the group message from any group member withoutchallenge, and such that a non-trusted group member receives the groupmessage from the subscriber subject to a receive setting.
 18. The methodas recited in claim 17, wherein the step for relaying a group message tothe group list from the subscriber, and relaying the group message fromany group member of the group list to the subscriber comprises: an actof the subscriber sending a group message to the group list; an act ofthe trusted group member receiving the group message from thesubscriber; and an act of the non-trusted group member challenging thegroup message from the subscriber based on the receive setting.
 19. Themethod as recited in claim 17, wherein first and second group messagesare created by any of the trusted or non-trusted group members and sentto the group list, and wherein the subscriber receives the first groupmessage based on content identified in the first group message, andwherein the subscriber does not receive the second group message due tocontent identified in the second group message.
 20. In a computerizedsystem including two or more group lists, a method for relaying messagesbetween group members of the two or more group lists based on one ormore trust relationships, such that a new group list does not need to beindependently joined or created, the method comprising: identifying afirst group list having one or more first group members; identifying asecond group list having one or more second group members; establishinga trust relationship between the first group list and the second grouplist; and sending a first group message by one first group member to thefirst group list, wherein the first group message is sent to the firstgroup list and to the second group list subject to a receive setting atany or both of the first and second group lists.
 21. The method asrecited in claim 20, wherein establishing a trust relationship betweenthe first group list and the second group list further comprises; afirst administrator of the first group list sending a trust indicator toa second group administrator of the second group list; and the secondgroup administrator sending a trust acceptance indicator to the firstgroup administrator.
 22. The method as recited in claim 20, wherein thereceive setting indicates that a group message sent by a subscriber tothe first group list is sent to the second group list subject to achallenge and response mechanism.
 23. In a computerized environment thatincludes an electronic messaging service, a group member, and one ormore group lists associated with the group member, a computer programproduct that includes computer-readable instructions that, whenexecuted, instruct a computerized system to perform a method ofcommunicating a group message between a subscriber and one or more groupmembers in the one or more group lists without the subscriber having toseparately join the one or more group lists, the method comprising: anact of identifying a group member; and a step for creating an electronicmessage trust relationship between a subscriber and the identified groupmember using a trust relationship, such that the subscriber cancommunicate with one or more group lists associated with the groupmember without requiring the subscriber to join the one or more grouplists.
 24. The computer program product as recited in claim 23, whereinthe step for creating an electronic message trust relationship includesthe acts of: an act of sending a trust indicator by the subscriber tothe identified group member; an act of receiving a trust acceptanceindicator that indicates that the group member has accepted the trustindicator, wherein the subscriber gains communicative access to a grouplist associated with the group member; and an act of sending a groupmessage from the group member or any other group members of theassociated group list to group list, such that the subscriber receivesthe group message.
 25. In a computerized environment that includes anelectronic messaging service, a group member, and one or more grouplists associated with the group member, a computer program product thatincludes computer-readable instructions that, when executed, instruct acomputerized system to perform a method of providing a subscriber withcommunicative access to at least one of the one or more groups based ona trust relationship, the method comprising the acts of: an act of agroup member of a group list accepting a trust indicator from asubscriber, such that the group member is a trusted group member; a stepfor, based on the accepted trust indicator, relaying a group message tothe group list from the subscriber, and relaying a group message fromany group member of the group list to the subscriber, such that thesubscriber receives the group message from any group member withoutchallenge, and such that a non-trusted group member receives the groupmessage from the subscriber subject to a receive setting.
 26. Thecomputer program product as recited in claim 25, wherein the step forrelaying a group message to the group list from the subscriber, andrelaying a group message from any of the one or more group members ofthe group list to the subscriber comprises: an act of the subscribersending a group message to the group list; an act of the trusted groupmember receiving the group message from the subscriber; and an act ofthe non-trusted group member challenging the group message from thesubscriber based on the receive setting.